home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Feb 91 / MacApp.Tech$ 2⁄15⁄91 / 2928-Re MacApp Source-Feb91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.8 KB  |  114 lines  |  [TEXT/GEOL]
  1. Item    5051479                         11-Feb-91        19:16
  2.  
  3. From:   KSAND@APPLE.COM@INTERNET#       Gateway to Internet/BITNET/UUCP
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. INTERNET# Document Id: <49065@apple.Apple.COM>
  8.  
  9. ------------------------------------------------------------------------------
  10.  
  11. Sub:    Re: MacApp Source
  12.  
  13. If you use AppleLink 6.0, you win! The Reply button works for gatewayed E-mail.
  14. Otherwise, copy & paste this: ksand@Apple.COM@INTERNET#
  15.  
  16. From: ksand@Apple.COM (Kent Sandvik)
  17. References: <3336175@AppleLink.Apple.COM>
  18. Lines: 87
  19. Organization: Apple Computer Inc., Cupertino, CA
  20. Newsgroups: apple.mac.app
  21. Path: apple!ksand
  22. To: macapp.tech$@applelink.apple.com
  23.  
  24.  
  25. Well, this starts to get far off a MacApp discussion, so this is my
  26. one and only answer. Due to the fact that my opinions are attacked
  27. I had to answer, otherwise let's got back to MacApp technical talking...
  28.  
  29. >????!!??!!!!?????????????????????????????????????????????????????????
  30. cute.
  31.  
  32. >1)  Providing class libraries without sources and good enough documentation to
  33. >use them is, no doubt, possible.  It's just something that is difficult to
  34. >accomplish and which with we have little experience.
  35.  
  36. It will happen, whether we want it or not.
  37.  
  38. >2)  MacApp is light-years beyond programming right on top of the toolbox and I
  39. >am continually amazed at how much the MacApp team has been able to accomplish
  40. >given their limited resources.  However, I do not believe MacApp is in a state
  41. >that will permit the creation of documentation that will replace the need for
  42. >access to source.
  43.  
  44. Also a questionable statement, but we all have opinions.
  45.  
  46. >3)  Inheritance mechanisms, as implemented in most object-oriented languages,
  47. >BREAK ENCAPSULATION.  The amount of documentation needed to effectively
  48. >subclass is far greater than that needed to simply to use as-is.  The whole
  49. >concept of MacApp as a framework REQUIRES the ability to suclass effectively.
  50.  
  51. Well, inheritance should not necessarily break encapsulation. If you
  52. rely on inherited code then you break, but if you try to follow any
  53. kinds of documentation rules about use of method overriding then you
  54. don't break. Actually, the idea of reusing existing method code for
  55. your own methods is a dangerous long term idea, because it makes life
  56. hard for a developer to track the changes in the internals of the method
  57. he/she used in the first place. And which is a contradiction of the
  58. whole idea of Object Design.
  59.  
  60. You have two reasons for inheritance overriding:
  61. a) Add some features, in which case you just call the old method as it
  62. is and add your functions.
  63. b) Totally modify the method, which firstly would seem to be a case
  64. where you need access to the code. But if you know by good documentation
  65. what the method does in the first place, then you don' need the sources.
  66.  
  67. >4)  More formal specifications of classes and their behaviours with language
  68. >features to enforce invariants, like Eiffel, could go a long way to making
  69. >object-code reusable libraries a reality.
  70.  
  71. A lot of people have the idea that you need a special form of a language
  72. in order to provide 'Software-IC's. Maybe that's the reason Cox and
  73. Meyer are so heavily proposing their languages as the only alternatives :-).
  74. C++ takes the standpoint of providing most of the language semantics
  75. in order to create software modules. With the advent of templates the
  76. language starts to get mature enough for creation of bullet-proof
  77. software object libraries, even if it could be done today as well with
  78. careful design.
  79.  
  80. >5)  One should not confuse the use of source code browsing as a means of more
  81. >fully understanding the behaviour of classes with depending on the internals
  82.  of
  83. >a class.  There exists a fine, but clear, distinction.  Afterall, if the
  84. >semantics were properly specified, or in some cases explicitly undefined, I
  85. >wouldn't have to look at the source code anyway- except for pedagogical
  86. >reasons.
  87.  
  88. This is a question of having the right tools, instead of having
  89. source code files (which in many cases are a clumsy way to look
  90. at dependencies compared with a special tool).
  91.  
  92. >6)  Ideally, we shouldn't require source.  Unfortunately, this is not the wo
  93. rld
  94. >we currently live in, though it eventually may be-  I hope.
  95.  
  96. Unfortunately the world we live in is full of copyrigths, licenses,
  97. trade marks, legions of laywers and greedy companies trying to
  98. steal stuff from each others.
  99.  
  100. Regards,
  101. Kent Sandvik
  102. ...please let's close this and talk about something more MacApp:ish.
  103.  
  104. >P.S.  Let me know the next time you subclass malloc or OpenPort.  ;-)
  105. PS: Let me know if you need access to malloc or OpenPort sources for
  106. your application development 8-|
  107.  
  108.  
  109. --
  110. Kent Sandvik, Apple Computer Inc, Developer Technical Support
  111. NET:ksand@apple.com, AppleLink: KSAND  DISCLAIMER: Private mumbo-jumbo
  112. Zippy++ says: "C++ is a write-only language, I can write programs in C++
  113. but I can't read any of them".
  114.